Background
The Sametime community server features TLS (Transport Layer Security) support for securing Sametime connections. This feature introduces numerous configuration settings that characterize the security aspects of TLS connections, as specified in Deploying > Deploying instant messaging > Installing Sametime Community Server > Securing the Sametime Community Server > Configuring Sametime Community Server to use SSL encryption > Setting up TLS Configuration. Some of the settings are mandatory, while others are optional. We define a setting as "optional" if TLS can function with its default value. However, the default value may not always comply with your organization's security requirements. This document discusses the potential weaknesses of TLS in Sametime, and the configuration settings that address each one of them.
Mandatory settings needed for deploying TLS
Establishing a TLS connection requires, at a minimum, a key store and a trust store. The key store resides at the TLS server side, while the trust store resides at the TLS client side. The key store contains the full server certificate, including the private key. The trust store contains the public certificate of the CA (certificate authority) which has signed the server certificate.
If the Sametime server configuration enables TLS between server-side components, you need both the key store and the trust store set in the server configuration. For example:
Sametime clients that wish to connect to the server over TLS will typically need a copy of the trust store file.
A configuration that specifies only the trust and key stores, while leaving all other TLS settings with the default values, does not impose the highest level of security. It is presented here to serve as a starting point. You may find it convenient to test a "loose" configuration such as this, before you proceed to building up stronger TLS configuration.
Considering Strict TLS vs Dynamic TLS
There are two options for enabling TLS in the community server:
- Strict TLS - The Community Server (port 1516) accepts only TLS connections. In this mode, the server rejects any attempt to login without a prior TLS handshake.
- Dynamic TLS - The Community Server (port 1516) accepts either TLS or non-TLS connections. Non-TLS connections may be created by old server components that are not capable of TLS - those are merely secured using Diffie-Hellman key exchange and RC2 encryption. When a TLS-capable server component connects to a server that listens to dynamic TLS port, the connection is initially established as non-TLS, and then, during the login sequence, the connection gets upgraded to TLS, without having to re-establish the TCP layer.
Dynamic TLS is a convenient feature for upgrading an existing deployment of Sametime. It allows a mixed environment of community server components, old and new, to inter-operate. If either endpoint is not TLS-capable, connection security remains as before, with Diffie-Hellman key exchange and RC2 encryption. If both endpoints are TLS-capable, the connection is automatically upgraded to TLS.
While dynamic TLS features backward compatibility with legacy servers, it is less secure than strict TLS, because it does not impose a specific security mechanism. The purpose of dynamic TLS is to incrementally migrate a Sametime deployment from legacy encryption to strict TLS, in a two-stage operation:
1. Enable dynamic TLS on each server in the deployment, one at a time, until all servers are in dynamic TLS mode.
2. Enable strict TLS on each server in the deployment, one at a time, until all servers are in strict TLS mode.
Considering client authentication
The TLS handshake protocol provides authentication using certificates.
Server authentication: The server presents its certificate to the client, allowing the client to authenticate the server.
Client authentication: The client presents its certificate to the server, allowing the server to authenticate the client.
The default TLS configuration denotes server authentication, but does not require client authentication.
Server authentication is not configurable - a server with a key store will always present its certificate to the client.
Client authentication is configurable, with 3 options to choose from:
- None: The server will not request a certificate from the client. This is the default value.
- Want: The server will request a certificate from the client, but will proceed with the handshake even if the client does not present one.
- Need: The server will request a certificate from the client, and will fail the connection if the client does not present one.
It is recommended to enable client authentication between server components. This instructs the community server to demand a client certificate when accepting connections on port 1516. Server components that reside on the same machine as the community server, may use the same key store file as the server, for this purpose. Remote server components will either need a copy of the server's key store file, or a key store that contains a certificate signed by the CA (certificate authority) that the server trusts.
The Mux, accepting client connections on port 1533, can be configured to request client authentication as well. However, this is not common practice, because Sametime clients already authenticate themselves using password (or token). If you do configure the Mux to require client authentication, it is then necessary to supply each client with a personal certificate, signed by a CA (certificate authority) that the Mux trusts.
You can configure TLS so the community server requires client certificates, but the Mux does not, like this:
Considering trusted hosts
During TLS handshake, the client validates the server certificate. There are two identities to validate in the certificate:
1. Signer - the CA (certificate authority) that signed the server certificate.
2. Subject - the identity of the server.
With the default configuration, only the signer is being validated, not the subject. Without inspecting the subject identity, the session is vulnerable to spoofing. For example, a man-in-the-middle can alter the IP packets, on the wire, redirecting the client's handshake message to a bogus server. The bogus server may present a certificate signed by a well-known CA, that the client trusts, although it is not the server that the client intends to communicate with. It is therefore recommended to validate both identities, signer and subject. With mutual authentication, where certificates are exchanged in both directions, the server may need to validate the client identity just as well.
In the Sametime server, the signer is validated according to the trust store, while the subject is validated against a configurable list of trusted hosts. By default, the list of trusted hosts is empty, which implies no subject validation. In order to enable certificate subject validation, you should specify, in configuration, one or more trusted hosts. To achieve this, there are two options in configuration to choose from:
1. Specify the list of trusted hosts, as explained in Setting up TLS Configuration, Procedure, Trusted certificate host names. When receiving a certificate from the peer, Sametime inspects the subject name, and compares it against the trusted hosts. The certificate may contain the subject name in the subject CN (common name) field, or in the subjectAltName extension. One match, between the certificate subject name and the trusted hosts setting, is enough for passing subject identity validation. The trusted hosts list may contain wildcard names, which allow matching a fragment of the domain name.
2. Mirror the trusted host according to the local key store. This is similar to setting a trusted hosts list, except the trusted host is automatically obtained, during runtime, from the server certificate in the local key store file. Mirroring trusted hosts is a convenient and secure option to establish trust between server components that use the same key store. Consider, for example, two servers in a cluster that connect over TLS. The TLS configuration of the two servers is identical, each using a copy of the same key store file. Let's assume that the server certificate, in the key store, is identified as sametime.ibm.com in the subjectAltName field. Having enabled trusted hosts mirroring, each server sets sametime.ibm.com as a trusted host. Then server1 connects to server2 over TLS:
1. server1 starts up and reads its TLS configuration. Since trusted hosts mirroring is enabled, the server retrieves the trusted host from its own certificate. It finds subjectAltName=sametime.ibm.com, and sets that string as the trusted host value.
2. server2 does the same as server1.
3. server1 initiates a TLS handshake with server2.
4. server2 sends its certificate, containing subjectAltName=sametime.ibm.com, to server1.
5. server1 verifies the certificate signer according to its local trust store.
6. server1 verifies the certificate subject, by comparing it to its own list of trusted hosts, which contains sametime.ibm.com, and authentication passes successfully.
Trusted hosts mirroring, combined with mutual TLS authentication, can be used to establish certificate-based trust between server-side components. Assuming Sametime clients do not have a personal certificate, this feature is enabled only in the server side, like this:
This configuration, on top of a strict TLS community server port, eliminates the need for the old trusted IPs mechanism. Administering > Administering a Sametime Community Server > Managing trusted IP addresses.
Considering the Security level
The security level setting imposes a standard security strength. During initialization, it asserts that all other TLS configuration settings, as well as certificate stores, meet the standard. During runtime, a strict security level will abort the handshake if the peer's certificate is too weak, or a session parameter fails to comply.
Security levels:
The default configuration value is "None", implying no standard level of security. This does not necessarily indicate weak configuration - you can still set up strong TLS configuration by modifying the following set of configuration settings. However, a specific security level ensures that each one of these settings complies with that standard. This is done automatically, during server startup, by adjusting the configuration value to meet the specified strength. Note the adjustments that are forced by the security level apply only to a runtime copy of the configuration, not the permanent configuration store.
- Trust store file - Trusted CA certificates that were signed with a weak algorithm, or a small key, or are otherwise not compliant with the security level, are discarded.
- Key store file - Certificates that were signed with a weak algorithm, or a small key, or are otherwise not compliant with the security level, are discarded.
- Minimum TLS protocol version - Protocol versions that are too old for the security level are discarded, so they are not offered in the handshake message.
- List of supported cipher suites - Weak cipher suites, that do not meet the security level, are discarded, so they are not offered in the handshake message.
Considering FIPS 140-2 compliance
The default configuration is not FIPS 140-2 compliant. If your Sametime deployment requires FIPS 140-2 compliance, set this in the TLS configuration:
Considering session renegotiation
A TLS session uses the same encryption key over and over again. An attacker capturing a large amount of cipher text, encrypted with the same key, might attempt to break the key material. Although strong cryptographic mechanisms make it hard to execute this kind of attack, the session key does lose its strength, little by little over time.
The default TLS configuration imposes no limit on the TLS session age, while it is generally recommended to renegotiate a session after 24 hours (86400 seconds) of usage:
Note: Sametime prevents the TLS renegotiation attack, by implementing the renegotiation indication extension, according to RFC 5746 (http://www.ietf.org/rfc/rfc5746.txt).
Considering certificate store passwords and password "stash" files
Certificate stores are password-protected. When the administrator sets the key and trust store passwords, in the TLS configuration page on the Sametime System Console, the password is stored, in cleartext form, in sametime.ini. For example:
The settings in the screenshot above produce the following text in sametime.ini:
ST_TLS_TRUST_STORE_FILE=trust.p12
ST_TLS_TRUST_STORE_PASSWORD=mysecret
Although the administrator can protect sametime.ini from unauthorized access, it may be incidentally necessary to disclose this file outside the organization. For example, a copy of sametime.ini is included in the Sametime diagnostics data (stdiagzip) that the administrator delivers to IBM support.
In order to keep sametime.ini clean of passwords, the administrator can "stash" the password in a separate file, which is not a part of the Sametime diagnostics. For example:
The settings in the screenshot above produce the following text in sametime.ini:
ST_TLS_TRUST_STORE_FILE=trust.p12
ST_TLS_TRUST_STORE_PASSWORD_STASH_FILE=password.sth
Creating the password stash file is explained in Deploying > Deploying instant messaging > Installing Sametime Community Server > Securing the Sametime Community Server > Configuring Sametime Community Server to use SSL encryption > Setting up TLS Configuration.
Considering the TLS protocol version
The default configuration enables TLS versions 1.0 through 1.2. If a standard security level is set, the minimum security level is adjusted to comply with that security level.
As a generic rule, the newer the protocol version in use, the more secure the TLS sessions are.
For maximum security, it is recommended to change the minimum version to TLS 1.2, to ensure that only the latest protocol version is in use:
Considering cipher suites
Sametime supports a variety of cipher suites, some highly secure, and others less. The default configuration allows all cipher suites, except for anonymous. If a standard security level is set, then cipher suites that do not comply with that security level are automatically discarded. Otherwise, if there is no security level setting, it is recommended to limit the set of supported cipher suites, so that only strong cryptographic algorithms are used.
To configure the cipher suites, scroll down to the "List of supported cipher suites" row of the table. Check the box next to the component which is being secured. For example: "LDAP", "Client Connections" or "Server Connections". Then type the list of ciphers in the box.
For example:
List of supported cipher suites:
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_RSA_WITH_AES_256_GCM_SHA384,TLS_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
Once complete, click OK at the bottom of the page. Repeat these steps on remaining Community servers.